The services that are carried in today's telecommunications network can be categorised into two main types; real time and non-real time services. The key examples of these two types are respectively voice telephony and computer data. The two services have very different characteristics and requirements and therefore have traditionally been carried over disjoint network technologies. However to increase flexibility and to decrease costs, there is a major drive by PTTs and network operators to integrate real-time and non-real time services within one homogeneous network. The asynchronous transfer mode (ATM) has been specifically designed to enable this.
A component of ATM is the adaptation function. This provides the mechanism that adapts the carried service to and from the ATM domain. Several adaptation layers have so far been defined. For example, ATM Adaptation Layer 1 (AAL1) is designed to adapt constant bit rate services (predominately voice or video) into fixed length ATM cells. A key feature of AAL1 is that it enables the timing relationship between the transmitter and receiver to be maintained over the asynchronous network. In contrast, AAL5 has been predominantly designed to support data services. As such it provides a mechanism to segment long data packets into fixed length ATM cells and a mechanism to enable the integrity of the reassembled data packet to be validated after transmission across the network. AAL5 is also being used in certain applications to carry voice services (particularly in computer desktop applications) where AAL5 technology is readily available.
Both AAL1 and AAL5 adapt the carried service into a stream of fixed length ATM cell payloads. However for certain compressed voice services the length of the ATM cell payload (48 bytes) is too large and its use would lead to a large packetisation delay that in turn would affect existing network delay budgets and acceptable voice characteristics. To resolve this problem AAL2 has been defined. AAL2 supports a multiplex of user channels within a single Virtual Channel Connection (VCC). Each user channel is carried in a stream of ‘mini-packets’—the length of the mini-packet payload for each channel can be defined according to the packetisation delay that can be tolerated. AAL2 differs from AAL1 and AAL5 in two key ways; firstly it enables a single VCC to support multiple diverse services (a number of simultaneous voice, video and data channels can be multiplexed together to reduce packetsation delay), and secondly it introduces a new switching layer above the ATM layer (i.e. the function of switching a mini-packet connection from one AAL2 VCC to another AAL2 VCC).
AAL2 has introduced a number of new issues to ATM scheduling and congestion control. These arise primarily from the characteristics of the traffic sources that AAL2 has been designed to support.
Traffic Classes Overview
ATM Traffic Classes
To accommodate the differing behaviours and QoS requirements for a variety of traffic sources, a set of traffic classes is defined in ATM. Each class is designed to describe the characteristics and requirements of a particular type of voice or data service. Five traffic classes have been defined by the ATM Forum [ATMF TM4]-CBR, rt-VBR, nrt-VBR, ABR and UBR.
However by its nature only the CBR and rt-VBR classes are appropriate for AAL2.
CBR
The CBR traffic class has been designed to support periodic traffic sources that have real-time requirements (i.e. they are delay sensitive). The traffic contract for a CBR connection is entirely specified by its Peak Cell Rate (PCR). The PCR specifies the peak emission rate of ATM cells (and thus implicitly the period between successive cells). All cells within the connection should conform to the PCR. Although the connection is described as CBR, it is perfectly admissible to transmit cells at lower than the PCR, or even to halt emission entirely.
Since the class is real-time, the ATM network commits to delivering cells within a specified delay and jitter bound (CTD and CDV).
rt-VBR
The real-time VBR class has been defined to support variable rate real time services (such as certain video streams). A rt-VBR connection is specified in terms of its Sustained Cell Rate (SCR), its Maximum Burst Size (MBS) and its PCR. The SCR defines the mean rate of the connection, the PCR defines the peak rate of any burst and the MBS defines the relationship between the two. Again, as this is a real time connection, the ATM network commits to delivering the service to specified delay and jitter bounds.
Policing of Connections
Once a connection has been established the ATM network commits to delivering it within the pre-specified QoS bounds providing the connection adheres to its traffic contract. The connection will be policed by the network at certain key interface points (typically the UNI and any inter-operator NNIs)—any cells that do not comply with the contract can be either discarded or tagged.
The Generic Cell Rate Algorithm (GCRA) (commonly known as a leaky bucket algorithm) has been defined to perform the policing function in ATM. The GCRA is generically specified through the use of two parameters—the Increment and Limit. The Increment specifies the anticipated period between conforming cells whilst the Limit specifies the allowed ‘relaxation’ from this increment for cells that arrive earlier than anticipated.
For a CBR connection the Increment is simply the reciprocal of the PCR. Due to the statistical effects of multiplexing sources together, jitter is introduced into a connection at all stages in the network (including at source as seen by the UNI). The allowable jitter, at each policed interface (e.g. a UNI or NNI), is termed the Cell Delay Variation Tolerance (CDVT). It is this parameter that is used for the GCRA Limit value in a CBR connection.
The generic GCRA algorithm can be summarised by the following pseudo-code:
if (cell_arrival_time > TAT) /* TAT is Theoretical Arrival Time */{ cell_conforms; TAT = cell_arrival_time + INC,}else if (cell_arrival_time > TAT − Limit){ cell_conformant; TAT = TAT + INC;}else cell_non_conformant;
Thus for a CBR connection the minimum interval between successive cells is equal to 1/PCR−CDVT. Any cells outside of this, can be marked as non-conformant and subsequently discarded if desired.
A rt-VBR connection on the other-hand must conform to both the PCR and SCR components of its traffic contract. To police this, two GCRAs operating in parallel are used to ensure compliance (each cell must comply to both GCRAs for the cell to be conformant). The first GCRA polices the peak rate of the connection (thus Increment=1/PCR, Limit=CDVT) whilst the second polices for the sustained rate. The sustained rate GCRA rate algorithm is defined by the parameters (Increment=1/SCR and Limit=BT+CDVT) where BT is the Burst Tolerance of the connection and is calculated by:BT=(MBS−1)(1/SCR−1/PCR)
AAL2 will be used primarily to support CBR Voice and VBR Voice traffic sources (although it can also support other delay sensitive traffic as well as data). It is important to note here the distinction between the individual AAL2 traffic sources and the underlying traffic class of the VCC bearer (CBR or rt-VBR VCC). In AAL2 it will be quite normal to use a CBR VCC to aggregate together a number of VBR Voice traffic sources or to use a rt-VBR VCC to support a mixture of CBR Voice and VBR Voice traffic sources.
A CBR Voice source is characterised by a periodic emission of constant rate data. CBR Voice sources include traditional 64 kb/s PCM (as typically carried by AAL1) or may arise through the use of constant rate CODECs with no silence suppression or down-speeding facility. CBR Voice sources are well understood and when multiple sources are multiplexed into a single VCC the aggregate will form a well-behaved CBR VCC connection (in an analogous manner to how CBR VCCs can be multiplexed together to form a CBR VPC). Congestion can therefore be prevented primarily through the use of appropriate Connection Admission Control (CAC) procedures.
VBR Voice is the term used to describe a traffic source generated by the use of a variable rate coding scheme and/or the utilisation of silence suppression. Generally, such sources still generate data at fixed periodic intervals, however now at each interval, the amount of data generated (the AAL2 packet payload length) can vary dynamically from packet to packet (down to zero during silent intervals). Such a voice source can therefore be characterised as an on-off source that has a variable bit rate during its on-period (albeit constrained to a small set of pre-defined CODEC rates) and an on-off distribution that is defined by the user's talkspurt behaviour. Unfortunately the multiplex of these sources no longer guarantees that the aggregate VCC obeys a well behaved CBR characteristic.
Assuming a nominal 50:50 talkspurt ratio each user spends approximately half their time in speech and the other half in silence. Therefore the mean occupancy on any bearer VCC will be half of that if silence suppression was not performed. However over any short time interval there is also a finite probability that fewer or greater than half the users will be active. These statistical fluctuations about the mean increase inversely with the number of users in the VCC pool. Therefore if the underlying bearer VCC is CBR with a capacity equating to the aggregate mean rate of the users, during periods where greater than half the users are active congestion will occur at the AAL2 multiplexing layer. Further due to the talkspurt characteristics, the duration of this congestion will typically be far longer than the normal cell-scale congestion that occurs naturally even when multiplexing pure CBR sources together. Simulations have shown that talkspurt congestion periods of several tens of milliseconds can arise when multiplexing multiple VBR Voice sources together over a low rate CBR VCC bearer connection.
There are a number of mechanisms to compensate for this potential talkspurt congestion. These include:                Use of a very rigorous CAC mechanism to minimise the probability of talkspurt congestion occurring. However for a VCC multiplexing together a low number of sources this is likely to lead to a poor statistical multiplexing gain (poor loading utilisation on the link).        Minimise talkspurt activity by traffic engineering. As the community of users increases the effects of talkspurt activity diminishes (the statistical fluctuation from the mean is smaller for larger groups of users). Thus by maximising the number of sources in a VCC or by aggregating multiple VCCs into a VPC (and policing at the VPC level not the VCC level) the potential for congestion due to talkspurt activity is minimised.        Accept that congestion will occur and provide sufficiently large buffers (at both source and sink) to compensate for it.        Dynamically down-speed connections during periods of talkspurt congestion. Some (but not all CODECS) can dynamically vary the connection bit-rate between a number of defined rates. (For example an ADPCM connection might select between 32 and 16 kb/s).        Use a rt-VBR traffic contract to enable the VCC cell rate to vary its bandwidth to cater for fluctuations in the aggregate bit rate of the traffic sources.        Minimise congestion by delaying lower priority traffic (i.e. delay insensitive) in favour of voice traffic during periods of high talk activity.        
In practice due to the sheer diversity of network applications for which AAL2 is likely to be used a combination of all of these methods may be employed (although obviously not at the same time on a single VCC). This places some general requirements on an AAL2 packet scheduler process which may be summarised as:
It should provide sufficient buffering to absorb talkspurt congestion.                It should have the ability to monitor for the onset of congestion at source either at the individual VCC level or at the device level as a whole. Detection of such congestion mechanisms should where possible enable alarms to be generated that can subsequently be applied to the traffic generating CODECS to indicate that they should apply down-speeding (if possible).        It must have the ability to generate AAL2 VCC connections having either a CBR or a rt-VBR traffic profile.        To minimise the the delay for real time services in favour of non-real time services AAL2 packet level prioritisation should be supported.        
The permissible emission rate of cells for an ATM VCC is governed by its traffic contract. For a CBR VCC this contract is specified in terms of a Peak Cell Rate (PCR). For a rt-VBR VCC the emission of cells must comply with its PCR, as well as its Sustained Cell Rate (SCR) and Maximum Burst Size (MBS). In the context of an AAL2 packet scheduler compliance to the specified bearer VCC traffic contract may be achieved by explicit enforcement, implicitly or a mixture of both.
With explicit conformance the AAL2 packet scheduler explicitly shapes its traffic to ensure compliance with the underlying bearer VCC traffic contract. Thus if the instantaneous packet rate (arriving at the scheduler) is greater than the contracted bearer rate then the scheduling of completed ATM cell payloads still remains in contract and the excess packets will be buffered within the packet scheduler buffer area.
In contrast, where implicit conformance is employed, the packet scheduler takes no account of the underlying bearer traffic contract—it is simply event driven by the arrival of new AAL2 packets. In this scenario the packet scheduler is effectively anticipating that the arrival of packets in itself will implicitly conform to the underling traffic contract. In effect this approach is relying on the CAC procedures being sufficiently stringent such that the probability of the contract being broken without explicit conformance is very low. Effectively the established traffic contract has been defined such that even under the ‘worst-case’ packet arrival scenarios rate the instantaneous arrival rate is still within the bounds of the contract and thus no further timing controls are required by the packet scheduler. However due to the nature of talkspurt behaviour it is unlikely that for the majority of cases this implicit timing approach will yield an efficient solution since (especially for low rate CBR VCCs) the contracted PCR would tend to need to greatly exceed the nominal sustained rate of the connection (due to statistical fluctuations)—in effect this would lead to a very low utilisation of the available bandwidth. (One other option when using implicit timing controls within the packet scheduler is to use a subsequent ATM device to reshape the emitted traffic to the underlying traffic contract.)
Alternatively a hybrid timing approach can also be used within the packet scheduler. In this scenario explicit timing is used to ensure compliance to the PCR only. Whilst this is sufficient in itself for CBR VCCs for rt-VBR VCCs compliance to the SCR and MBS is not enforced. Instead in the hybrid approach the traffic contract is established such that providing the PCR is complied to the arrival of packets will not cause the SCR or MBS to be exceeded (in effect SCR and MBS are instead implicitly enforced by defining appropriate limits at connection setup.
The introduction of AAL2 has introduced a number of new issues relating to ATM scheduling and congestion control, and in particular the problem of efficient bandwidth utilisation. These arise primarily from the nature of the traffic sources, particularly voice, which AAL2 has been designed to support.